Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000004_owner-urn-ietf _Fri Nov 1 10:58:50 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27704 for urn-ietf-out; Fri, 1 Nov 1996 10:58:50 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27699 for <[e-mail]>; Fri, 1 Nov 1996 10:58:47 -0500
Received: from workstation1.swip.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA06202  (mail destined for [e-mail]); Fri, 1 Nov 96 10:58:45 -0500
Received: (from leslie@localhost) by pluto.swip.net (8.7.6/8.6.12) id QAA06560; Fri, 1 Nov 1996 16:58:41 +0100 (MET)
Date: Fri, 1 Nov 1996 16:58:41 +0100 (MET)
From: Leslie Daigle <[e-mail]>
X-Sender: [e-mail]
To: Daniel LaLiberte <[e-mail]>
Cc: [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: [e-mail]
Precedence: bulk
Reply-To: Leslie Daigle <[e-mail]>
Errors-To: [e-mail]

[Dan LaLiberte wrote:]

> OK, what is a location?  Is it the bits on the disk that "has" the

Well, here's my perspective:

A URL (location) is a point in 4-space, as defined by:

=09. machine (aliased through DNS mechanisms)
=09. port number (default per protocol)
=09. protocol to speak on that port and at that machine
=09. string to use within that protocol

A basic URN (name) has nothing to do with these 4 dimensions -- it is=20
independent of any machine identifier, port, or protocol.  The string
associated with it is a _label_ that is unique across the specified
namespace.

> Consider caches.  The resolution of a URL via a cache proxy may find
> the resource in the cache rather than in some remote server.  What is
> "the location" of the resource in that case?

Caches are external to either URN or URL systems.  They may choose to use
the URL string as a label that identifies a particular resource, and use
that label to lookup contents of the cache.  But, caches break when
the label does not change, but the contents of the location does.  If you
cache based on URN, your cache will not break, because the content associat=
ed
with the identifier does not change.

> Here is an example of how what is thought of as a location really
> turns out to *be* a name (as in persistent location).  Take a normal
> http URL such as http://www.ncsa.uiuc.edu/.  Instead of using normal
> HTTP to resolve the URL, or to look it up in a cache, let's set up a
> NAPTR-based "http" naming authority.  Under that branch of the name
> space, we could ask the appropriate DNS server to look up
> 'www.ncsa.uiuc.edu' to find out where a server is currently located
> and what "resolution protocols" are currently supported.
>=20
> We don't need to create a new kind of identifier to make a URL into a
> persistent location.  We *do* need new persistent services, such as
> the NAPTR records in DNS.

I'm not sure I understand the point you are making here.  It sounds like
you are saying -- forget everything else about all this stuff, let's=20
do NAPTR as a service, and then people can build in persistence using
whichever mechansisms strike their fancy?

I have a problem with that approach, for (at least) two reasons:

=09. implementing a persistent location means adding much overhead
=09  in systems that were not built for it.

=09. there are then no mechanisms to distinguish between things that
=09  are meant to be persistent, and things that are expected not
=09  to be. =20


> To summarize, both URLs and URNs have the following abstract
> resolution process in common:
>=20
> 1. Do some client-specific processing of the URI - maybe end there.
> 2. Look at the scheme name of the URI.  If it says "URN:" drop it and rep=
eat.
> 3. Look up the scheme in local table to find out what process should
>    be invoked.  E.g. news URIs may use NNTP, http URIs may use HTTP,
>    cid URIs may use NAPTR-protocol.
> 4. Invoke the process identified by step 3.=20
> 5. If error results, exit.
> 6. If redirected to another URI, repeat whole process with that URI.
>=20

It is definitely interesting to look at the surface similarities in mechani=
cs
between URL resolution and the NAPTR approach to URN handling.  What still
is not clear to me is what you are suggesting to _do_ with this.  If you
are suggesting that there is nothing more to do with URN work than to
define different steps in 2 and 3, I have a problem with that...

Leslie.



---------------------------------------------------------------------------=
-
                                                  Leslie Daigle
   "Min sv=E4vare =E4r full av =E5lar!"        Vice President, Research
                                                  Bunyip Information System=
s
                      -- ThinkingCat              [phone]
                                                  [e-mail]
---------------------------------------------------------------------------=
-